博文推荐｜消息系统的发展趋势：云原生是未来

本文转载自公众号 StreamCloudNative，作者薛松，就职于新大陆软件，担任高级软件工程师。

关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。
当前已有众多国内外大型互联网和传统行业公司采用 Apache Pulsar，案例分布在人工智能、金融、电信运营商、直播与短视频、物联网、零售与电子商务、在线教育等多个行业，如美国有线电视网络巨头 Comcast、Yahoo！、腾讯、中国电信、中国移动、BIGO、VIPKID 等。

---

什么是消息系统？

消息系统是应用程序或商业伙伴之间传递数据的重要部分，是指系统的客户之间的原始数据通过格式化、编码形成可发送的消息，然后在通讯系统之间进行传输，最后被获取、解码、解释执行的一系列规则与方法。

目前消息系统已经广泛使用于互联网企业，各类业务系统都有它的身影，一方面是其传统的功能特点：系统间调用的异步解耦，减低系统的复杂度、流量的削峰填谷，便于业务弹性伸缩、易于实现最终一致性系统，避免分布式事务对性能的影响、支持 P2P (点对点的调用) 和 pub/sub 模式减少 RPC 的多次调用（广播通知机制）等。另外随着业务的快速增长，企业内部需要大量数据的同步传输，流式计算等应用都需要非常稳定高效的传输通道给予支持，消息系统在其中充当了重要的角色。

基本的术语和概念

消息 （Message），是消息系统中最小的概念，本质上就是一段数据，它能被一个或者多个应用程序所理解，是应用程序之间传递的信息载体。

消息队列（MQ），是一种应用程序对应用程序的通信方法，应用程序通过队列进行通信，而不是通过直接调用彼此来通信，队列的使用除去了接收和发送应用程序同时执行的要求。是进行通信的中间件产品。

主流的消息系统

消息系统的功能

1.消息系统对企业异构系统集成有着重要的使用场景，各系统遵循协商的数据规范进行生产和消费消息，系统间通讯从传统 RPC 服务接口调用方式转换到数据协议的通讯方式，使得系统耦合度降低，责任边界更明确，同时有利于系统升级发布，可持续集成部署。
2.消息通知机制，使得系统异步处理变得简单，同步调用需要阻塞当前线程等待结果返回，会影响系统的并发能力，而消息通知方式是由上游业务将请求转化为消息的形式发往消息中间件 (MOM) 即可返回，无需等待后续业务处理，下游获取消息后异步的处理后续逻辑。
3.业务流量的削峰填谷，传统 RPC 同步调用 (PUSH 模型) 在应对突增性流量时，一般采用扩容/降级/熔断等机制来保护下游核心服务的正常运行，而消息系统在调用中间层增加了一道缓冲机制，暴增流量发生时，通过消息积压的方式存储在Broker 中，下游服务根据自身处理能力，量力而行的拉取消息进行消费，不会给后续服务带来毁灭性冲击。
4.消息系统易于业务实现最终一致性场景，传统的强一致性的事务，一般通过二阶段或三阶段提交方式来实现，但是性能较差容易造成性能瓶颈，通过消息系统的消息通知机制和补偿手段来达到分布式系统的数据一致，很大程度上改善了系统性能和吞吐能力。
5.支持P2P 和 pub/sub 模型和广播机制，比如缓存通知，需要更新所有本地缓存，RPC 的方式实现，每接入一个新业务方需要调一次方法，难以动态接入和灵活性较差，消息系统绝大多数支持广播的方式，极大简化业务逻辑处理和提供灵活接入的能力。
6.快速数据传输，为在线流式计算提供可靠的数据通道。分布式环境中各类异构数据源分散杂糅，高效快速的归集数据，并为实时数据分析模型高效地传导数据，对现代互联网企业有着至关重要的作用。

消息系统的发展趋势

为什么使用消息系统？

1.解耦 
在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2.冗余 
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
3.扩展性 
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
4.灵活性 & 峰值处理能力 
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
5.可恢复性 
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
6.顺序保证 
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
7.缓冲 
在任何重要的系统中，都会有需要不同的处理时间的元素。例如，加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行，写入队列的处理会尽可能的快速。该缓冲有助于控制和优化数据流经过系统的速度。
8.异步通信 
很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把消息放入队列，但并不立即处理它，然后在需要的时候再去获取消息消费它们。

消息系统的对比

ActiveMQ

ActiveMQ 是由 Apache 发布、一个完全支持 JMS1.1 和J2EE 1.4 规范的 JMS Provider 实现。它非常快速，支持多种语言的客户端和协议，而且可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

主要特性：

•遵从 JMS 规范：JMS 规范提供了良好的标准和保证，包括：同步或异步的消息分发，一次和仅一次的消息分发，消息接收和订阅等等。遵从 JMS 规范的好处在于，不论使用什么 JMS 实现提供者，这些基础特性都是可用的；•连接性：ActiveMQ 提供了广泛的连接选项，支持的协议有：HTTP/S，IP 多播，SSL，STOMP，TCP，UDP，XMPP 等等。对众多协议的支持让ActiveMQ 拥有了很好的灵活性。•支持的协议种类多：OpenWire、STOMP、REST、XMPP、AMQP ；•持久化插件和安全插件：ActiveMQ 提供了多种持久化选择。而且，ActiveMQ 的安全性也可以完全依据用户需求进行自定义鉴权和授权；•支持的客户端语言种类多：除了Java 之外，还有C/C++，.NET，Perl，PHP，Python，Ruby；•代理集群：多个 ActiveMQ 代理可以组成一个集群来提供服务；•异常简单的管理：ActiveMQ 是以开发者思维被设计的。所以，它并不需要专门的管理员，因为它提供了简单又实用的管理特性。有很多方法可以监控 ActiveMQ 不同层面的数据，•包括使用在 JConsole 或者 ActiveMQ 的 Web Console 中使用 JMX，通过处理 JMX 的告警消息，通过使用命令行脚本，甚至可以通过监控各种类型的日志。

RabbitMQ

RabbitMQ 是一个在 AMQP (高级消息队列协议) 基础上完成的，可复用的企业消息系统，是当前最主流的消息中间件之一。

主要特性：

•可靠性: 提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制；•灵活的路由：消息在到达队列前是通过交换机进行路由的。RabbitMQ 为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做 RabbitMQ 的插件来使用；•消息集群：在相同局域网中的多个 RabbitMQ 服务器可以聚合在一起，作为一个独立的逻辑代理来使用；•队列高可用：队列可以在集群中的机器上进行镜像，以确保在硬件问题下还保证消息安全；•多种协议的支持：支持多种消息队列协议；服务器端用Erlang 语言编写，支持只要是你能想到的所有编程语言；•管理界面: RabbitMQ 有一个易用的用户界面，使得用户可以监控和管理消息Broker 的许多方面；•跟踪机制：如果消息异常，RabbitMQ 提供消息跟踪机制，使用者可以找出发生了什么；•插件机制：提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

RocketMQ

RocketMQ 是出自阿里公司的开源产品，用Java 语言实现，在设计时参考了 Kafka，并做出了自己的一些改进，消息可靠性上比 Kafka 更好。RocketMQ 在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等场景。

主要特性：

•是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点；•Producer、Consumer、队列都可以分布式；•Producer 向一些队列轮流发送消息，队列集合称为 Topic，Consumer 如果做广播消费，则一个 Consumer 实例消费这个 Topic 对应的所有队列，如果做集群消费，则多个 Consumer 实例平均消费这个 Topic 对应的队列集合；•能够保证严格的消息顺序；•提供丰富的消息拉取模式；•高效的订阅者水平扩展能力；•实时的消息订阅机制；•亿级消息堆积能力；•较少的依赖。

Kafka

Apache Kafka 是一个分布式消息发布订阅系统。它最初由 LinkedIn 公司基于独特的设计实现为一个分布式的提交日志系统 (a distributed commit log)，之后成为 Apache 项目的一部分。Kafka 系统快速、可扩展并且可持久化。它的分区特性，可复制和可容错都是其不错的特性。

主要特性：

•快速持久化，可以在 O(1) 的系统开销下进行消息持久化；•高吞吐，在一台普通的服务器上既可以达到10W/s 的吞吐速率；•完全的分布式系统，Broker、Producer、Consumer 都原生自动支持分布式，自动实现负载均衡；•支持同步和异步复制两种 HA；•支持数据批量发送和拉取；•zero-copy：减少 IO 操作步骤；•数据迁移、扩容对用户透明；•无需停机即可扩展机器；•其他特性：严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制。

Pulsar

Apache Pulsar 是最初由 Yahoo! 创建的云原生分布式消息系统和流平台，现在是顶级 Apache Software Foundation 的项目。Pulsar ⽀持统⼀的 Queue 和 Stream 的接⼝，具有⾼性能和强⼀致性，云原⽣架构：存储计算分离，分层 + 分片，具备丰富的企业级特性，多租户隔离，并且支持百万级 Topics，跨地域复制，鉴权认证等。

主要特性：

•存储与计算分离，可以快速的水平伸缩服务；

•多租户，租户间资源隔离；

•Schema，定义在 Topic 上的数据结构体，实现消息处理标准化，避免在读写消息时重复的序列化和反序列化带来冗余的工作•Pulsar Function 流处理，提供函数式接口，无需部署其它第三方的流处理引擎，如Storm、SparkStreaming、Flink 等；

•Pulsar SQL，支持基于 Presto OLAP 实时在线分析引擎对 Pulsar 中的数据和其它第三方存储引擎的数据进行海量多维数据的统计分析；

•分层存储，允许将较旧的积压数据从 BookKeeper 移至长期且价格便宜的存储中，同时仍然允许客户端访问积压数据；

•跨地域复制，不同的数据中心之间的数据复制；

•IO 连接器，提供丰富的外部系统与 Pulsar 交互的插件；

•云化，支持 K8S，Docker 等容器化部署；•多语言客户端，支持 Java、C++、Go、Python、Node.js 等语言客户端；•运维监控，采用 Prometheus + Grafana 监控工具，对 Pulsar 集群的状态实时监控；•集群管理，Pulsar Manager 提供了友好的界面管理工具，可以对集群、存储、租户、名称空间、Topic 等方面的监控和管理；•丰富的生态圈，Pulsar 集成了大数据、流处理、云化、IO 扩展、并支持多语言客户端，提供了丰富的功能。

总结

目前，在所有的消息系统中，ActiveMQ 和 RabbitMQ 作为老一代消息系统，已经逐渐被替代；在业界最为熟知的是 Kafka，它的分布式、高吞吐、水平扩展以及稳定性都表现的非常优秀，也是在许多公司的业务系统中被广泛使用；RocketMQ 作为阿里主打的消息系统，号称能够扛住双十一峰值的压力，在金融领域有比较好的表现；Pulsar 作为新一代的消息系统，集成了其它消息系统的优势，并提供了丰富的功能特性以及生态圈，是其它消息系统所不具备的，而且 Pulsar 是完全开源的，拥有活跃的社区团队，开发者可以在核心版本的基础上添加定制化的功能，Pulsar 主打流、云原生的概念，符合未来技术的发展趋势。

作为架构师、开发者在消息系统的选型时，可以根据业务场景的需求、运维管理、版本的发布等方面，选择符合项目需要的消息系统。

相关阅读

欢迎投稿

Apache Pulsar 社区欢迎大家踊跃投稿。Apache Pulsar 和 StreamNative 希望为大家提供 Pulsar 经验与知识分享的平台，并帮助更多的社区小伙伴深入了解 Pulsar。扫码添加 Bot 好友即可联络投稿👇

---

点击下方，阅读原文吧！